QueryParams.build() retained a name whose value list was empty, leaving an
entry that reported contains() == true but rendered nothing from encode().
Two instances that encode() to the same string could therefore compare
unequal and hash differently, breaking the documented "equal iff encode()
identical" invariant.

Skip names with no values when building, so a name added with an empty list
never persists as a phantom entry. A value-less parameter keeps its single
empty-string value and is unaffected.

OperationRequestAssembler appended the resolved path and query to the base
URL verbatim, with no handling for a base URL that already carried a query.
A signed base such as https://host/container?sig=... therefore had the path
spliced into the query value (https://host/container?sig=.../pets?limit=20),
corrupting both the path and the signature, and java.net.URL accepted the
result so the breakage only surfaced at the server.

Split any query off the base URL first, insert the resolved path before it,
and append the operation query after it, so base + path + query compose
correctly. Reject a fragment on the base URL (it cannot be composed with a
path/query and is never sent on the wire), and translate a malformed base
URL into IllegalArgumentException instead of leaking the checked
MalformedURLException out of toRequest().

…position

- encode reserved '*' as %2A and keep unreserved '~' literal in PercentEncoding
- preserve a significant trailing slash and avoid a doubled '&' when composing
  operation request URLs over a base URL that already carries path/query
- read a query param via a direct scan instead of building a throwaway
  QueryParams multimap per page

OperationParams exposes an operationName for instrumentation, but
toRequestContext discarded it — it promoted the DispatchContext without
passing the name on, so the value never reached the context chain that
the HttpTracerFactory.newTracer(operationName, ...) seam reads from. A
service that set operationName still produced unlabelled contexts.

Thread operationName through the promotion chain:

- RequestContext and ExchangeContext gain an optional operationName,
  forwarded on promotion (RequestContext -> ExchangeContext).
- DispatchContext.toRequestContext takes an optional operationName;
  @jvmoverloads keeps the existing single-argument method.
- OperationParams.toRequestContext passes its operationName, so a named
  operation labels its context for tracing without affecting the
  assembled request's URL, headers, or body.

Regenerate the sdk-core API snapshot and update the Operation Input
Projection docs. Tests cover propagation through each link of the chain.

OperationRequestAssembler left a trailing '&' from the base URL's query
in place when the operation contributed no query of its own, emitting a
dangling `?a=1&`. Trim a single trailing separator before merging so the
base query joins cleanly whether or not an operation query follows.

Widen the path-template variable pattern from `[^/}]` to `[^}]` so a
malformed `{a/b}` placeholder is captured whole and fails fast as a
missing path parameter, instead of leaking an unsubstituted `{a/b}`
literal into the assembled URL.